Conditionally parsed extension syntax for HEVC extension processing

ABSTRACT

A system for signaling extension functions used in decoding a sequence including a plurality of pictures, each picture processed at least in part according to a picture parameter set is disclosed. An extension presence signaling flag is read and used to determine whether flags signaling the performance of extension functions are to be read. The flags are only read if indicated by the extension presence signaling flag.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/411,092, filed May 13, 2019, which is a continuation of U.S. patentapplication Ser. No. 14/585,485, filed Dec. 30, 2014, now U.S. Pat. No.10,341,685, issued Jul. 2, 2019, which claims benefit of U.S.Provisional Patent Application No. 61/923,334, filed Jan. 3, 2014, allof which are incorporated herein by reference in their entireties.

BACKGROUND Field of the Invention

The present invention relates to systems and methods for encoding anddecoding data, and in particular to a system and method for generatingand processing slice headers with high efficiency video coded data.

Description of the Related Art

There is rapid growth in the technologies associated with thegeneration, transmission, and reproduction of media programs. Thesetechnologies include coding schemes that permit digital versions of themedia programs to be encoded to compress them to much smaller size andfacilitate their transmission, storage, reception and playback. Thesetechnologies have application in personal video recorders (PVRs), videoon demand (VOD), multiple channel media program offerings,interactivity, mobile telephony, and media program transmission.

Without compression, digital media programs are typically too large totransmit and/or store for a commercially acceptable cost. However,compression of such programs has made the transmission and storage ofsuch digital media programs not only commercially feasible, butcommonplace.

Initially, the transmission of media programs involved low to mediumresolution images transmitted over high bandwidth transmission mediasuch as cable television and satellite. However, such transmission hasevolved to include lower bandwidth transmission media such as Internettransmission to fixed and mobile devices via computer networks, WiFi,Mobile TV and third and fourth generation (3G and 4G) networks. Further,such transmissions have also evolved to include high definition mediaprograms such as high definition television (HDTV), which havesignificant transmission bandwidth and storage requirements.

The High Efficiency Video Coding (HEVC) coding standard (or H.265) isthe most recent coding standard promulgated by the ISO/IEC MPEGstandardization organizations. The coding standard preceding HEVCincluded the H.262/MPEG-2 and the subsequent H.264/MPEG-4 Advanced VideoCoding (AVC) standard. H.264/MPEG-4 has substantially replacedH.262/MPEG-2 in many application including high definition (HD)television. HEVC supports resolutions higher than HD, even in stereo ormulti-view embodiments, and is more suitable for mobile devices such astablet personal computers. Further information regarding HEVC can befound in the publication “Overview of the High Efficiency Video Coding(HEVC) Standard, by Gary J. Sullivan, Jens-Rainer Ohm, Woo-Jin Han andThomas Wiegand, IEEE Transactions on Circuits and Systems for VideoTechnology, December 2012, which is hereby incorporated by referenceherein.

As in other coding standards, the bit stream structure and syntax ofHEVC compliant data are standardized, such that every decoder conformingto the standard will produce the same output when provided with the sameinput. Some of the features incorporated into the HEVC standard includethe definition and processing of a slice, one or more of which maytogether comprise one of the pictures in a video sequence. A videosequence comprises a plurality of pictures, and each picture maycomprise one or more slices. Slices include non-dependent slices anddependent slices. A non-dependent slice (hereinafter simply referred toas a slice) is a data structure that can be decoded independently fromother slices of the same picture in terms of entropy encoding, signalprediction, and residual signal construction. This data structurepermits resynchronization of events in case of data losses. A “dependentslice” is a structure that permits information about the slice (such asthose related with tiles within the slice or wavefront entries) to becarried to the network layer, thus making that data available to asystem to more quickly process fragmented slices. Dependent slices aremostly useful for low-delay encoding.

HEVC and legacy coding standards define a parameter set structure thatoffers improved flexibility for operation over a wide variety ofapplications and network environments, and improved robustness to datalosses. Parameter sets contain information that can be shared fordecoding of different portions of the encoded video. The parameter setstructure provides a secure mechanism for conveying data that isessential to the decoding process. H.264 defined both sequence parametersets (SPS) that describe parameters for decoding a sequence of picturesand a picture parameter set (PPS) that describes parameters for decodinga picture of the sequence of pictures. HEVC introduces a new parameterset, the video parameter set (VPS).

The encoding and decoding of slices is performed according toinformation included in a slice header. The slice header includes syntaxand logic for reading flags and data that are used in decoding theslice.

Like its predecessors, HEVC supports both temporal and spatial encodingof picture slices. HEVC defines slices to include I-slices, which arespatially, but not temporally encoded with reference to another slice.I-slices are alternatively described as “intra” slice encoded. HEVC alsodefines slices to include P (predictive) slices, which are spatiallyencoded and temporally encoded with reference to another slice. P-slicesare alternatively described as “inter” slice encoded. HEVC alsodescribes slices to include bi-predictive (B)-slices. B-slices arespatially encoded and temporally encoded with reference to two or moreother slices. Further, HEVC consolidates the notion of P and B slicesinto general B slices that can be used as reference slice.

Currently, the HEVC syntax includes provision for extensions to expandthe capabilities or capacities of HEVC beyond the baseline. Suchextensions include range extensions (RExt, scalability extensions(SHVC), and multi-view extensions (MV-HEVC). Extensions may be signaledin the VPS, SPS, PPS, or combination thereof.

High Efficiency Video Coding (HEVC) Range Extensions text specification:Draft 4,” published by the Joint Collaborative Team on Video Coding(JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 13thMeeting: Incheon, KR, 18-26 Apr. 2013, by David Flynn et al, (herebyincorporated by reference herein) defines a PPS syntax that controlledthe execution of multiple extension functions by use of extensionfunction-unique flags uniquely associated with each extension function.However, such flags were not independently read. For example, a firstflag signaling the execution of one extension function in the PPS syntaxmay be read within syntax that is only parsed and executed if another(second) flag for a previously executed extension function has aparticular state or value (e.g. a flag may not read unless thepreviously read flag tests “true”). This is not problematic when theexecution of an extension function is not desired unless the previousextension function syntax has been executed. But it is problematic incases where it is desirable to control the parsing or execution of theextension functions independently. What is needed is an improved systemand method for parsing syntax that permits the parsing of extensionfunctions to be independently controlled. This disclosure describes sucha system and method.

SUMMARY

To address the requirements described above, this document discloses adevice and method for signaling extension functions used in decoding asequence comprising a plurality of pictures, each picture processed atleast in part according to a picture parameter set. In one embodiment,the method comprises reading an extension presence signaling flag,determining if the read extension presence signaling flag indicates thatthe picture is to be processed at least in part according to at leastone extension function, and reading a first extension function signalingflag signaling a first extension function and reading a second extensionfunction signaling flag signaling a second extension independently of avalue of the read first extension function signaling flag only if theread extension presence signaling flag indicates that the picture is tobe processed at least in part according to the at least one extensionfunction. This method can be performed with additional extensionfunction signaling flags as necessary. Another embodiment is disclosedin which an apparatus is evidenced by a processor having acommunicatively coupled memory storing instructions for performing theforegoing operations.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 is a diagram depicting an exemplary embodiment of a videocoding-decoding system that can be used for transmission and/or storageand retrieval of audio and/or video information;

FIG. 2A is a diagram of one embodiment of a codec system in which theencoded AV information is transmitted to and received at anotherlocation;

FIG. 2B is a diagram depicting an exemplary embodiment of codec systemin which the encoded information is stored and later retrieved forpresentation, hereinafter referred to as codec storage system;

FIG. 2C is a diagram depicting another embodiment for a contentdistribution system comprising a coding system or encoder and decodingsystem or decoder for transmitting and receiving HEVC data.

FIG. 3 is a block diagram illustrating one embodiment of the sourceencoder;

FIG. 4 is a diagram depicting a picture of AV information, such as oneof the pictures in the picture sequence;

FIG. 5 is a diagram showing an exemplary partition of a coding treeblock into coding units;

FIG. 6 is a diagram illustrating a representation of a representativequad tree and data parameters for the code tree block partitioning shownin FIG. 5;

FIG. 7 is a diagram illustrating the partition of a coding unit into oneor more prediction units;

FIG. 8 is a diagram showing a coding unit partitioned into fourprediction units and an associated set of transform units;

FIG. 9 is a diagram showing RQT codetree for the transform unitsassociated with the coding unit in the example of FIG. 8;

FIG. 10 is a diagram illustrating spatial prediction of predictionunits;

FIG. 11 is a diagram illustrating temporal prediction;

FIG. 12 is a diagram illustrating the use of motion vector predictors(MVPs);

FIG. 13 illustrates an example of the use of the reference picturelists;

FIG. 14 is a diagram illustrating processes performed by the encoderaccording to the aforementioned standard;

FIG. 15 depicts the use of a the collocated_from_10_flag by the decoderin decoding a according to the emerging HEVC standard;

FIGS. 16A and 16B are diagrams presenting a baseline PPS syntax;

FIGS. 17A-17D illustrate an exemplary improved processing flows andsyntax for extension processing;

FIG. 18 is a diagram presenting an exemplary PPS syntax for HEVC rangeextension;

FIGS. 19A-19C show further alternate embodiments of extension signalingsyntax; and

FIG. 20 illustrates an exemplary processing system that could be used toimplement the disclosed embodiments.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanyingdrawings which form a part hereof, and which is shown, by way ofillustration, several embodiments of the present invention. It isunderstood that other embodiments may be utilized and structural changesmay be made without departing from the scope of the present invention.

Audio-Visual Information Transception and Storage

FIG. 1 is a diagram depicting an exemplary embodiment of a videocoding-decoding (codec) system 100 that can be used for transmissionand/or storage and retrieval of audio and/or video information. Thecodec system 100 comprises an encoding system 104, which acceptsaudio-visual (AV) information 102 and processes the AV information 102to generate encoded (compressed) AV information 106, and a decodingsystem 112, which processes the encoded AV information 106 to producerecovered AV information 114. Since the encoding and decoding processesare not lossless, the recovered AV information 114 is not identical tothe initial AV information 102, but with judicious selection of theencoding processes and parameters, the differences between the recoveredAV information 114 and the unprocessed AV information 102 are acceptableto human perception.

The encoded AV information 106 is typically transmitted or stored andretrieved before decoding and presentation, as performed by transception(transmission and reception) or storage/retrieval system 108.Transception losses may be significant, but storage/retrieval losses aretypically minimal or non-existent, hence, the transcepted AV information110 provided to the decoding system 112 is typically the same as orsubstantially the same as the encoded AV information 106.

FIG. 2A is a diagram of one embodiment of a codec system 200A in whichthe encoded AV information 106 is transmitted to and received at anotherlocation. A transmission segment 230 converts an input AV information102 into a signal appropriate for transmission and transmits theconverted signal over the transmission channel 212 to the receptionsegment 232. The reception segment 232 receives the transmitted signal,and converts the received signal into the recovered AV information 114for presentation. As described above, due to coding and transmissionlosses and errors, the recovered AV information 114 may be of lowerquality than the AV information 102 that was provided to thetransmission segment 230. However, error-correcting systems may beincluded to reduce or eliminate such errors. For example, the encoded AVinformation 106 may be forward error correction (FEC) encoded by addingredundant information, and such redundant information can be used toidentify and eliminate errors in the reception segment 230.

The transmission segment 102 comprises one or more source encoders 202to encode multiple sources of AV information 102. The source encoder 202encodes the AV information 102 primarily for purposes of compression toproduce the encoded AV information 106, and may include, for example aprocessor and related memory storing instructions implementing a codecsuch as MPEG-1, MPEG-2, MPEG-4 AVC/H.264, HEVC or similar codec, asdescribed further below.

The codec system 200A may also include optional elements indicated bythe dashed lines in FIG. 2A. These optional elements include a videomultiplex encoder 204, an encoding controller 208, and a videodemultiplexing decoder 218. The optional video multiplex encoder 204multiplexes encoded AV information 106 from an associated plurality ofsource encoder(s) 202 according to one or more parameters supplied bythe optional encoding controller 208. Such multiplexing is typicallyaccomplished in the time domain and is data packet based.

In one embodiment, the video multiplex encoder 204 comprises astatistical multiplexer, which combines the encoded AV information 106from a plurality of source encoders 202 so as to minimize the bandwidthrequired for transmission. This is possible, since the instantaneous bitrate of the coded AV information 106 from each source encoder 202 canvary greatly with time according to the content of the AV information102. For example, scenes having a great deal of detail and motion (e.g.sporting events) are typically encoded at higher bitrates than sceneswith little motion or detail (e.g. portrait dialog). Since each sourceencoder 202 may produce information with a high instantaneous bitratewhile another source encoder 202 produces information with a lowinstantaneous bit rate, and since the encoding controller 208 cancommand the source encoders 202 to encode the AV information 106according to certain performance parameters that affect theinstantaneous bit rate, the signals from each of the source encoders 106(each having a temporally varying instantaneous bit rate) can becombined together in an optimal way to minimize the instantaneous bitrate of the multiplexed stream 205.

As described above, the source encoder 202 and the video multiplex coder204 may optionally be controlled by a coding controller 208 to minimizethe instantaneous bit rate of the combined video signal. In oneembodiment, this is accomplished using information from a transmissionbuffer 206 which temporarily stores the coded video signal and canindicate the fullness of the buffer 206. This allows the codingperformed at the source encoder 202 or video multiplex coder 204 to be afunction of the storage remaining in the transmission buffer 206.

The transmission segment 230 also may comprise a transmission encoder210, which further encodes the video signal for transmission to thereception segment 232. Transmission encoding may include for example,the aforementioned FEC coding and/or coding into a multiplexing schemefor the transmission medium of choice. For example, if the transmissionis by satellite or terrestrial transmitters, the transmission encoder114 may encode the signal into a signal constellation beforetransmission via quadrature amplitude modulation (QAM) or similarmodulation technique. Also, if the encoded video signal is to bestreamed via an Internet protocol device and the Internet, thetransmission encodes the signal according to the appropriate protocol.Further, if the encoded signal is to be transmitted via mobiletelephony, the appropriate coding protocol is used, as further describedbelow.

The reception segment 232 comprises a transmission decoder 214 toreceive the signal that was coded by the transmission coder 210 using adecoding scheme complementary to the coding scheme used in thetransmission encoder 214. The decoded received signal may be temporarilystored by optional reception buffer 216, and if the received signalcomprises multiple video signals, the received signal is multiplexdecoded by video multiplex decoder 218 to extract the video signal ofinterest from the video signals multiplexed by the video multiplex coder204. Finally, the video signal of interest is decoded by source decoder220 using a decoding scheme or codec complementary to the codec used bythe source encoder 202 to encode the AV information 102.

In one embodiment, the transmitted data comprises a packetized videostream transmitted from a server (representing the transmitting segment230) to a client (representing the receiving segment 232). In this case,the transmission encoder 210 may packetize the data and embed networkabstract layer (NAL) units in network packets. NAL units define a datacontainer that has header and coded elements, and may correspond to avideo frame or other slice of video data.

The compressed data to be transmitted may packetized and transmitted viatransmission channel 212, which may include a Wide Area Network (WAN) ora Local Area Network (LAN). Such a network may comprise, for example, awireless network such as WiFi, an Ethernet network, an Internet networkor a mixed network composed of several different networks. Suchcommunication may be affected via a communication protocol, for exampleReal-time Transport Protocol (RTP), User Datagram Protocol (UDP) or anyother type of communication protocol. Different packetization methodsmay be used for each network abstract layer (NAL) unit of the bitstream. In one case, one NAL unit size is smaller than the maximumtransport unit (MTU) size corresponding to the largest packet size thatcan be transmitted over the network without being fragmented. In thiscase, the NAL unit is embedded into a single network packet. In anothercase, multiple entire NAL units are included in a single network packet.In a third case, one NAL unit may be too large to be transmitted in asingle network packet and is thus split into several fragmented NALunits with each fragmented NAL unit being transmitted in an individualnetwork packet. Fragmented NAL unit are typically sent consecutively fordecoding purposes.

The reception segment 232 receives the packetized data and reconstitutesthe NAL units from the network packet. For fragmented NAL units, theclient concatenates the data from the fragmented NAL units in order toreconstruct the original NAL unit. The client 232 decodes the receivedand reconstructed data stream and reproduces the video images on adisplay device and the audio data by a loud speaker.

FIG. 2B is a diagram depicting an exemplary embodiment of codec systemin which the encoded information is stored and later retrieved forpresentation, hereinafter referred to as codec storage system 200B. Thisembodiment may be used, for example, to locally store information in adigital video recorder (DVR), a flash drive, hard drive, or similardevice. In this embodiment, the AV information 102 is source encoded bysource encoder 202, optionally buffered by storage buffer 234 beforestorage in a storage device 236. The storage device 236 may store thevideo signal temporarily or for an extended period of time, and maycomprise a hard drive, flash drive, RAM or ROM. The stored AVinformation is then retrieved, optionally buffered by retrieve buffer238 and decoded by the source decoder 220.

FIG. 2C is another diagram depicting an exemplary content distributionsystem 200C comprising a coding system or encoder 202 and a decodingsystem or decoder 220 that can be used to transmit and receive HEVCdata. In some embodiments, the coding system 202 can comprise an inputinterface 256, a controller 241 a counter 242 a frame memory 243, anencoding unit 244, a transmitter buffer 267 and an output interface 257.The decoding system 220 can comprise a receiver buffer 259, a decodingunit 260, a frame memory 261 and a controller 267. The coding system 202and the decoding system 220 can be coupled with each other via atransmission path which can carry a compressed bit stream. Thecontroller 241 of the coding system 202 can control the amount of datato be transmitted on the basis of the capacity of the transmitter buffer267 or receiver buffer 259 and can include other parameters such as theamount of data per a unit of time. The controller 241 can control theencoding unit 244 to prevent the occurrence of a failure of a receivedsignal decoding operation of the decoding system 220. The controller 241can be a processor or include, by way of a non-limiting example, amicrocomputer having a processor, a random access memory and a read onlymemory.

Source pictures 246 supplied from, by way of a non-limiting example, acontent provider can include a video sequence of frames including sourcepictures in a video sequence. The source pictures 246 can beuncompressed or compressed. If the source pictures 246 are uncompressed,the coding system 202 can have an encoding function. If the sourcepictures 246 are compressed, the coding system 202 can have atranscoding function. Coding units can be derived from the sourcepictures utilizing the controller 241. The frame memory 243 can have afirst area that can be used for storing the incoming frames from thesource pictures 246 and a second area that can be used for reading outthe frames and outputting them to the encoding unit 244. The controller241 can output an area switching control signal 249 to the frame memory243. The area switching control signal 249 can indicate whether thefirst area or the second area is to be utilized.

The controller 241 can output an encoding control signal 250 to theencoding unit 244. The encoding control signal 250 can cause theencoding unit 202 to start an encoding operation, such as preparing theCoding Units based on a source picture. In response to the encodingcontrol signal 250 from the controller 241, the encoding unit 244 canbegin to read out the prepared Coding Units to a high-efficiencyencoding process, such as a prediction coding process or a transformcoding process which process the prepared Coding Units generating videocompression data based on the source pictures associated with the CodingUnits.

The encoding unit 244 can package the generated video compression datain a packetized elementary stream (PES) including video packets. Theencoding unit 244 can map the video packets into an encoded video signal248 using control information and a program time stamp (PTS) and theencoded video signal 248 can be transmitted to the transmitter buffer267.

The encoded video signal 248, including the generated video compressiondata, can be stored in the transmitter buffer 267. The informationamount counter 242 can be incremented to indicate the total amount ofdata in the transmitter buffer 267. As data is retrieved and removedfrom the buffer, the counter 242 can be decremented to reflect theamount of data in the transmitter buffer 267. The occupied areainformation signal 253 can be transmitted to the counter 242 to indicatewhether data from the encoding unit 244 has been added or removed fromthe transmitter buffer 267 so the counter 242 can be incremented ordecremented. The controller 241 can control the production of videopackets produced by the encoding unit 244 on the basis of the occupiedarea information 253 which can be communicated in order to anticipate,avoid, prevent, and/or detect an overflow or underflow from taking placein the transmitter buffer 267.

The information amount counter 242 can be reset in response to a presetsignal 254 generated and output by the controller 241. After theinformation amount counter 242 is reset, it can count data output by theencoding unit 244 and obtain the amount of video compression data and/orvideo packets, which have been generated. The information amount counter242 can supply the controller 241 with an information amount signal 255representative of the obtained amount of information. The controller 241can control the encoding unit 244 so that there is no overflow at thetransmitter buffer 267.

In some embodiments, the decoding system 220 can comprise an inputinterface 266, a receiver buffer 259, a controller 267, a frame memory261, a decoding unit 260 and an output interface 267. The receiverbuffer 259 of the decoding system 220 can temporarily store thecompressed bit stream, including the received video compression data andvideo packets based on the source pictures from the source pictures 246.The decoding system 220 can read the control information andpresentation time stamp information associated with video packets in thereceived data and output a frame number signal 263 which can be appliedto the controller 220. The controller 267 can supervise the countednumber of frames at a predetermined interval. By way of a non-limitingexample, the controller 267 can supervise the counted number of frameseach time the decoding unit 260 completes a decoding operation.

In some embodiments, when the frame number signal 263 indicates thereceiver buffer 259 is at a predetermined capacity, the controller 267can output a decoding start signal 264 to the decoding unit 260. Whenthe frame number signal 263 indicates the receiver buffer 259 is at lessthan a predetermined capacity, the controller 267 can wait for theoccurrence of a situation in which the counted number of frames becomesequal to the predetermined amount. The controller 267 can output thedecoding start signal 263 when the situation occurs. By way of anon-limiting example, the controller 267 can output the decoding startsignal 264 when the frame number signal 263 indicates the receiverbuffer 259 is at the predetermined capacity. The encoded video packetsand video compression data can be decoded in a monotonic order (i.e.,increasing or decreasing) based on presentation time stamps associatedwith the encoded video packets.

In response to the decoding start signal 264, the decoding unit 260 candecode data amounting to one picture associated with a frame andcompressed video data associated with the picture associated with videopackets from the receiver buffer 259. The decoding unit 260 can write adecoded video signal 269 into the frame memory 261. The frame memory 261can have a first area into which the decoded video signal is written,and a second area used for reading out decoded pictures 262 to theoutput interface 267.

In various embodiments, the coding system 202 can be incorporated orotherwise associated with a transcoder or an encoding apparatus at aheadend and the decoding system 220 can be incorporated or otherwiseassociated with a downstream device, such as a mobile device, a set topbox or a transcoder.

Source Encoding/Decoding

As described above, the encoders 202 employ compression algorithms togenerate bit streams and/or files of smaller size than the originalvideo sequences in the AV information 102. Such compression is madepossible by reducing spatial and temporal redundancies in the originalsequences.

Prior art encoders 202 include those compliant with the videocompression standard H.264/MPEG-4 AVC (“Advanced Video Coding”)developed by between the “Video Coding Expert Group” (VCEG) of the ITUand the “Moving Picture Experts Group” (MPEG) of the ISO, in particularin the form of the publication “Advanced Video Coding for GenericAudiovisual Services” (March 2005), which is hereby incorporated byreference herein.

HEVC “High Efficiency Video Coding” (sometimes known as H.265) isexpected to replace the H.264/MPEG-4 AVC. HEVC introduces new codingtools and entities that are generalizations of the coding entitiesdefined in H.264/AVC, as further described below.

FIG. 3 is a block diagram illustrating one embodiment of the sourceencoder 202. The source encoder 202 accepts AV information 102 and usessampler 302 sample the AV information 102 to produce a sequence 303 ofsuccessive of digital images or pictures, each having a plurality ofpixels. A picture can comprise a frame or a field, wherein a frame is acomplete image captured during a known time interval, and a field is theset of odd-numbered or even-numbered scanning lines composing a partialimage.

The sampler 302 produces an uncompressed picture sequence 303. Eachdigital picture can be represented by one or more matrices having aplurality of coefficients that represent information about the pixelsthat together comprise the picture. The value of a pixel can correspondto luminance or other information. In the case where several componentsare associated with each pixel (for example red-green-blue components orluminance-chrominance components), each of these components may beseparately processed.

Images can be segmented into “slices,” which may comprise a portion ofthe picture or may comprise the entire picture. In the H.264 standard,these slices are divided into coding entities called macroblocks(generally blocks of size 16 pixels×16 pixels) and each macroblock mayin turn be divided into different sizes of data blocks 102, for example4×4, 4×8, 8×4, 8×8, 8×16, 16×8. HEVC expands and generalizes the notionof the coding entity beyond that of the macroblock.

HEVC Coding Entities: CTU, CU, PU and TU

Like other video coding standards, HEVC is a block-based hybrid spatialand temporal predictive coding scheme. However, HEVC introduces newcoding entities that are not included with H.264/AVC standard. Thesecoding entities include (1) Coding tree block (CTUs), coding units(CUs), the predictive units (PUs) and transform units (TUs) and arefurther described below.

FIG. 4 is a diagram depicting a picture 400 of AV information 102, suchas one of the pictures in the picture sequence 303. The picture 400 isspatially divided into non-overlapping square blocks known as codingtree units(s), or CTUs 402. Unlike H.264 and previous video codingstandards where the basic coding unit is macroblock of 16×16 pixels, theCTU 402 is the basic coding unit of HEVC, and can be as large as 128×128pixels. As shown in FIG. 4, the CTUs 402 are typically referenced withinthe picture 400 in an order analogous to a progressive scan.

Each CTU 402 may in turn be iteratively divided into smaller variablesize coding units described by a “quad tree” decomposition furtherdescribed below. Coding units are regions formed in the image to whichsimilar encoding parameters are applied and transmitted in the bitstream 314.

FIG. 5 is a diagram showing an exemplary partition of an CTU 402 intocoding units (CUs) such as coding unit 502A and 502B (hereinafteralternatively referred to as coding unit(s) 502). A single CTU 402 canbe divided into four CUs 502 such as CU 502A, each a quarter of the sizeof CTU 402. Each such divided CU 502A can be further divided into foursmaller CUs 502B of quarter size of initial CU 502A.

The division of CTUs 402 into CUs 502A and into smaller CUs 502B isdescribed by “quad tree” data parameters (e.g. flags or bits) that areencoded into the output bit stream 314 along with the encoded data asoverhead known as syntax.

FIG. 6 is a diagram illustrating a representation of a representativequad tree 600 and data parameters for the CTU 402 partitioning shown inFIG. 5. The quad tree 600 comprises a plurality of nodes including firstnode 602A at one hierarchical level and second node 602B at a lowerhierarchical level (hereinafter, quad tree nodes may be alternativelyreferred to as “nodes” 602). At each node 602 of a quad tree, a “splitflag” or bit “1” is assigned if the node 602 is further split intosub-nodes, otherwise a bit “0” is assigned.

For example, the CTU 402 partition illustrated in FIG. 5 can berepresented by the quad tree 600 presented in FIG. 6, which includes asplit flag of “1” associated with node 602A at the top CU 502 level(indicating there are 4 additional nodes at a lower hierarchical level).The illustrated quad tree 600 also includes a split flag of “1”associated with node 602B at the mid CU 502 level to indicate that thisCU is also partitioned into four further CUs 502 at the next (bottom) CUlevel. The source encoder 202 may restrict the minimum and maximum CU502 sizes, thus changing the maximum possible depth of the CU 502splitting.

The encoder 202 generates encoded AV information 106 in the form of abit stream 314 that includes a first portion having encoded data for theCUs 502 and a second portion that includes overhead known as syntaxelements. The encoded data includes data corresponding to the encodedCUs 502 (i.e. the encoded residuals together with their associatedmotion vectors, predictors, or related residuals as described furtherbelow). The second portion includes syntax elements that may representencoding parameters which do not directly correspond to the encoded dataof the blocks. For example, the syntax elements may comprise an addressand identification of the CU 502 in the image, a quantization parameter,an indication of the elected Inter/Intra coding mode, the quad tree 600or other information.

CUs 502 correspond to elementary coding elements and include two relatedsub-units: prediction units (PUs) and a transform units (TUs), both ofwhich have a maximum size equal to the size of the corresponding CU 502.

FIG. 7 is a diagram illustrating the partition of a CU 502 into one ormore PUs 702. A PU 702 corresponds to a partitioned CU 502 and is usedto predict pixels values for intra-picture or inter-picture types. PUs702 are an extension of the partitioning of H.264/AVC for motionestimation, and are defined for each CU 502 that is not furthersubdivided into other CUs (“split flag”=0). At each leaf 604 of the quadtree 600, a final (bottom level) CU 502 of 2N×2N can possess one of fourpossible patterns of PUs: 2N×2N (702A), 2N×N (702B), N×2N (702C) and N×N(702D)), as shown in FIG. 7.

A CU 502 can be either spatially or temporally predictive coded. If a CU502 is coded in “intra” mode, each PU 702 of the CU 502 can have its ownspatial prediction direction and image information as further describedbelow. Also, in the “intra” mode, the PU 702 of the CU 502 may depend onanother CU 502 because it may use a spatial neighbor, which is inanother CU. If a CU 502 is coded in “inter” mode, each PU 702 of the CU502 can have its own motion vector(s) and associated referencepicture(s) as further described below.

FIG. 8 is a diagram showing a CU 502 partitioned into four PUs 702 andan associated set of transform units (TUs) 802. TUs 802 are used torepresent the elementary units that are spatially transformed by a DCT(Discrete Cosine Transform). The size and location of each blocktransform TU 802 within a CU 502 is described by a “residual” quad tree(RQT) further illustrated below.

FIG. 9 is a diagram showing RQT 900 for TUs 802 for the CU 502 in theexample of FIG. 8. Note that the “1” at the first node 902A of the RQT900 indicates that there are four branches and that the “1” at thesecond node 902B at the adjacent lower hierarchical level indicates thatthe indicated node further has four branches. The data describing theRQT 900 is also coded and transmitted as an overhead in the bit stream314.

The coding parameters of a video sequence may be stored in dedicated NALunits called parameter sets. Two types of parameter sets NAL units maybe employed. The first parameter set type is known as a SequenceParameter Set (SPS), and comprises a NAL unit that includes parametersthat are unchanged during the entire video sequence. Typically, an SPShandles the coding profile, the size of the video frames and otherparameters. The second type of parameter set is known as a PictureParameter Set (PPS), and codes different values that may change from oneimage to another.

Spatial and Temporal Prediction

One of the techniques used to compress a bit stream 314 is to forego thestorage of pixel values themselves and instead, predict the pixel valuesusing a process that can be repeated at the decoder 220 and store ortransmit the difference between the predicted pixel values and theactual pixel values (known as the residual). So long as the decoder 220can compute the same predicted pixel values from the informationprovided, the actual picture values can be recovered by adding theresiduals to the predicted values. The same technique can be used tocompress other data as well.

Referring back to FIG. 3, each PU 702 of the CU 502 being processed isprovided to a predictor module 307. The predictor module 307 predictsthe values of the PUs 702 based on information in nearby PUs 702 in thesame frame (intra-frame prediction, which is performed by the spatialpredictor 324) and information of PUs 702 in temporally proximate frames(inter-frame prediction, which is performed by the temporal predictor330). Temporal prediction, however, may not always be based on acollocated PU, since collocated PUs are defined to be located at areference/non-reference frame having the same x and y coordinates as thecurrent PU 702. These techniques take advantage of spatial and temporaldependencies between PUs 702.

Encoded units can therefore be categorized to include two types: (1)non-temporally predicted units and (2) temporally predicted units.Non-temporally predicted units are predicted using the current frame,including adjacent or nearby PUs 702 within the frame (e.g. intra-frameprediction), and are generated by the spatial predictor 324. Temporallypredicted units are predicted from one temporal picture (e.g. P-frames)or predicted from at least two reference pictures temporally aheadand/or behind (i.e. B-frames).

Spatial Prediction

FIG. 10 is a diagram illustrating spatial prediction of PUs 702. Apicture may comprise a PU 702 and spatially proximate other PUs 1-4,including nearby PU 702N. The spatial predictor 324 predicts the currentblock (e.g. block C of FIG. 10) by means of an “intra-frame” predictionwhich uses PUs 702 of already-encoded other blocks of pixels of thecurrent image.

The spatial predictor 324 locates a nearby PU (e.g. PU 1, 2, 3 or 4 ofFIG. 10) that is appropriate for spatial coding and determines anangular prediction direction to that nearby PU. In HEVC, 35 directionscan be considered, so each PU may have one of 35 directions associatedwith it, including horizontal, vertical, 45 degree diagonal, 135 degreediagonal, DC etc. The spatial prediction direction of the PU isindicated in the syntax.

Referring back to the spatial predictor 324 of FIG. 3, this locatednearby PU is used to compute a residual PU 704 (e) as the differencebetween the pixels of the nearby PU 702N and the current PU 702, usingelement 305. The result is an intra-predicted PU element 1006 thatcomprises a prediction direction 1002 and the intra-predicted residualPU 1004. The prediction direction 1002 may be coded by inferring thedirection from spatially proximate PUs, and the spatial dependencies ofthe picture, enabling the coding rate of the intra prediction directionmode to be reduced.

Temporal Prediction

FIG. 11 is a diagram illustrating temporal prediction. Temporalprediction considers information from temporally neighboring pictures orframes, such as the previous picture, picture i−1.

Generally, temporal prediction includes single-prediction (P-type),which predicts the PU 702 by referring to one reference area from onlyone reference picture, and multiple prediction (B-type), which predictsthe PU by referring to two reference areas from one or two referencepictures. Reference images are images in the video sequence that havealready been coded and then reconstructed (by decoding).

The temporal predictor 330 identifies, in one or several of thesereference areas (one for P-type or several for B-type), areas of pixelsin a temporally nearby frame so that they can be used as predictors ofthis current PU 702. In the case where several areas predictors are used(B-type), they may be merged to generate one single prediction. Thereference area 1102 is identified in the reference frame by a motionvector (MV) 1104 that is defines the displacement between the current PU702 in current frame (picture i) and the reference area 1102 (refIdx) inthe reference frame (picture i−1). A PU in a B-picture may have up totwo MVs. Both MV and refIdx information are included in the syntax ofthe HEVC bit stream.

Referring again to FIG. 3, a difference between the pixel values betweenof the reference area 1102 and the current PU 702 may be computed byelement 305 as selected by switch 306. This difference is referred to asthe residual of the inter-predicted PU 1106. At the end of the temporalor inter-frame prediction process, the current PU 1006 is composed ofone motion vector MV 1104 and a residual 1106.

However, as described above, one technique for compressing data is togenerate predicted values for the data using means repeatable by thedecoder 220, computing the difference between the predicted and actualvalues of the data (the residual) and transmitting the residual fordecoding. So long as the decoder 220 can reproduce the predicted values,the residual values can be used to determine the actual values.

This technique can be applied to the MVs 1104 used in temporalprediction by generating a prediction of the MV 1104, computing adifference between the actual MV 1104 and the predicted MV 1104 (aresidual) and transmitting the MV residual in the bit stream 314. Solong as the decoder 220 can reproduce the predicted MV 1104, the actualMV 1104 can be computed from the residual. HEVC computes a predicted MVfor each PU 702 using the spatial correlation of movement between nearbyPUs 702.

FIG. 12 is a diagram illustrating the use of motion vector predictors(MVPs) in HEVC. Motion vector predictors V₁, V₂ and V₃ are taken fromthe MVs 1104 of a plurality of blocks 1, 2, and 3 situated nearby oradjacent the block to encode (C). As these vectors refer to motionvectors of spatially neighboring blocks within the same temporal frameand can be used to predict the motion vector of the block to encode,these vectors are known as spatial motion predictors.

FIG. 12 also illustrates temporal motion vector predictor V_(T) which isthe motion vector of the co-located block C′ in a previously decodedpicture (in decoding order) of the sequence (e. g. block of picture i−1located at the same spatial position as the block being coded (block Cof image i).

The components of the spatial motion vector predictors V₁, V₂ and V₃ andthe temporal motion vector predictor V_(T) can be used to generate amedian motion vector predictor V_(M). In HEVC, the three spatial motionvector predictors may be taken as shown in FIG. 12, that is, from theblock situated to the left of the block to encode (V₁), the blocksituated above (V₃) and from one of the blocks situated at therespective corners of the block to encode (V₂), according to apredetermined rule of availability. This MV predictor selectiontechnique is known as Advanced Motion Vector Prediction (AMVP).

A plurality of (typically five) MV predictor (MVP) candidates havingspatial predictors (e.g. V₁, V₂ and V₃) and temporal predictor(s) V_(T)is therefore obtained. In order to reduce the overhead of signaling themotion vector predictor in the bit stream, the set of motion vectorpredictors may reduced by eliminating data for duplicated motion vectors(for example, MVs which have the same value as other MVs may beeliminated from the candidates).

The encoder 202 may select a “best” motion vector predictor from amongthe candidates, and compute a motion vector predictor residual as adifference between the selected motion vector predictor and the actualmotion vector, and transmit the motion vector predictor residual in thebit stream 314. To perform this operation, the actual motion vector mustbe stored for later use by the decoder 220 (although it is nottransmitted in the bit stream 314. Signaling bits or flags are includedin the bit stream 314 to specify which MV residual was computed from thenormalized motion vector predictor, and are later used by the decoder torecover the motion vector. These bits or flags are further describedbelow.

Referring back to FIG. 3, the intra-predicted residuals 1004 and theinter-predicted residuals 1106 obtained from the spatial (intra) ortemporal (inter) prediction process are then transformed by transformmodule 308 into the transform units (TUs) 802 described above. A TU 802can be further split into smaller TUs using the RQT decompositiondescribed above with respect to FIG. 9. In HEVC, generally 2 or 3 levelsof decompositions are used and authorized transform sizes are from32×32, 16×16, 8×8 and 4×4. As described above, the transform is derivedaccording to a discrete cosine transform (DCT) or discrete sinetransform (DST).

The residual transformed coefficients are then quantized by quantizer310. Quantization plays a very important role in data compression. InHEVC, quantization converts the high precision transform coefficientsinto a finite number of possible values. Although the quantizationpermits a great deal of compression, quantization is a lossy operation,and the loss by quantization cannot be recovered.

The coefficients of the quantized transformed residual are then coded bymeans of an entropy coder 312 and then inserted into the compressed bitstream 310 as a part of the useful data coding the images of the AVinformation. Coding syntax elements may also be coded using spatialdependencies between syntax elements to increase the coding efficiency.HEVC offers context-adaptive binary arithmetic coding (CABAC). Otherforms or entropy or arithmetic coding may also be used.

In order to calculate the predictors used above, the encoder 202 decodesalready encoded PUs 702 using “decoding” loop 315, which includeselements 316, 318, 320, 322, 328. This decoding loop 315 reconstructsthe PUs and images from the quantized transformed residuals.

The quantized transform residual coefficients E are provided todequantizer 316, which applies the inverse operation to that ofquantizer 310 to produce dequantized transform coefficients of theresidual PU (E′) 708. The dequantized data 708 is then provided toinverse transformer 318 which applies the inverse of the transformapplied by the transform module 308 to generate reconstructed residualcoefficients of the PU (e′) 710.

The reconstructed coefficients of the residual PU 710 are then added tothe corresponding coefficients of the corresponding predicted PU (x′)702′ selected from the intra-predicted PU 1004 and the inter-predictedPU 1106 by selector 306. For example, if the reconstructed residualcomes from the “intra” coding process of the spatial predictor 324, the“intra” predictor (x′) is added to this residual in order to recover areconstructed PU (x″) 712 corresponding to the original PU 702 modifiedby the losses resulting from a transformation, for example in this casethe quantization operations. If the residual 710 comes from an “inter”coding process of the temporal predictor 330, the areas pointed to bythe current motion vectors (these areas belong to the reference imagesstored in reference buffer 328 referred by the current image indices)are merged then added to this decoded residual. In this way the originalPU 702 is modified by the losses resulting from the quantizationoperations.

To the extent that the encoder 202 uses motion vector predictiontechniques analogous to the image prediction techniques described above,the motion vector may be stored using motion vector buffer 329 for usein temporally subsequent frames. As further described below, a flag maybe set and transferred in the syntax to indicate that the motion vectorfor the currently decoded frame should be used for at least thesubsequently coded frame instead of replacing the contents of the MVbuffer 329 with the MV for the current frame.

A loop filter 322 is applied to the reconstructed signal (x″) 712 inorder to reduce the effects created by heavy quantization of theresiduals obtained, and to improve the signal quality. The loop filter322 may comprise, for example, a deblocking filter for smoothing bordersbetween PUs to visually attenuate high frequencies created by the codingprocess and a linear filter that is applied after all of the PUs for animage have been decoded to minimize the sum of the square difference(SSD) with the original image. The linear filtering process is performedon a frame by frame basis and uses several pixels around the pixel to befiltered, and also uses spatial dependencies between pixels of theframe. The linear filter coefficients may be coded and transmitted inone header of the bit stream typically a picture or slice header.

The filtered images, also known as reconstructed images, are then storedas reference images from reference image buffer 328 in order to allowthe subsequent “Inter” predictions taking place during the compressionof the subsequent images of the current video sequence.

Reference Image Syntax

As described above, to reduce errors and improve compression, HEVCpermits the use of several reference images for the estimation andmotion compensation of the current image. Given a current PU 702 in acurrent picture, the collocated PU 1102 for a particular slice residesin associated nearby reference/non-reference picture. For example, inFIG. 12, the collocated PU 1102 for current PU 702 in picture (i)resides in the associated nearby reference picture (i−1). The best“inter” or temporal predictors of the current PU 702 are selected insome of the multiple reference/non-reference images, which may be basedon pictures temporally prior to or after the current picture in displayorder (backwards and forward prediction, respectively).

For HEVC, the index to reference pictures is defined by referencepicture lists that are described in the slice syntax. Forward predictionis defined by list_0 (RefPicList0), and backward prediction is definedby list_1 (RefPicList1), and both list 0 and list 1 can contain multiplereference pictures prior to or/and later than the current picture in thedisplay order.

FIG. 13 illustrates an example of the use of the reference picturelists. Consider pictures 0, 2, 4, 5, 6, 8 and 10 shown in FIG. 13,wherein the numbers of each picture denote display order and the currentpicture is picture 5. In this case, the list_0 reference pictures withascending reference picture indices and starting with index equal tozero are 4, 2, 0, 6, 8 and 10, and the list_1 reference pictures withascending reference picture indices and starting with index equal tozero are 6, 8, 10, 4, 2, and 0. A slice that the motion compensatedprediction is restricted to the list_0 prediction is called a predictiveor P-slice. Collocated pictures are indicated by using thecollocated_ref_idx index in the HEVC. A slice for which themotion-compensated prediction includes more than one reference pictureis a bi-predictive or B-slice. For B-slices, the motion compensatedprediction may include reference pictures from list_1 prediction as wellas list_0.

Hence, a collocated PU 1102 is disposed in a reference picture specifiedin either list_0 or list_1. A flag (collocated_from_l0_flag) is used tospecify whether the collocated partition should be derived from list_0or list_1 for a particular slice type. Each of the reference pictures isalso associated with a motion vector.

The storage and retrieval of reference pictures and related motionvectors for the emerging HEVC standard is expressed in paragraph8.4.1.2.9 of Benjamin Bross, Woo-Jin Han, Jens-Rainer Ohm, Gary J.Sullivan, Thomas Wiegand, “WD4: Working Draft 4 of High-Efficiency VideoCoding,” Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16WP3 and ISO/IEC JTC1/SC29/WG11, JCTVC-F803_d5, 6th Meeting: Torino, IT,14-22 Jul., 2011 (hereby incorporated by reference herein).

According to the standard, if the slice_type is equal to B and thecollocated_from_l0_flag is 0, the collocated_ref_idx variable specifiesthe reference picture as the picture that contains the co-locatedpartition as specified by RefPicList1. Otherwise (slice_type is equal toB and collocated_from_l0_flag is equal to 1 or slice_type is equal toP), the collocated_ref_idx variable specifies the reference picture asthe picture that contains the collocated partition as specified byRefPicList0.

FIG. 14 is a diagram illustrating processes performed by the encoder 202according to the aforementioned standard. Block 1402 determines whetherthe current picture is a reference picture for another picture. If not,there is no need to store reference picture or motion vectorinformation. If the current picture is a reference picture for anotherpicture, block 1504 determines whether the “another” picture is a P-typeor a B-type picture. If the picture is a P-type picture, processing ispassed to blocks 1410, which set the colloc_from_10_flag to one andstore the reference picture and motion vector in list 0. If the “anotherpicture” is a B-type picture, block 1406 nonetheless directs processingto blocks 1408 and 1410 if the desired reference picture is to be storedin list 0, and to blocks 1412 and 1414 if the desired reference pictureand motion vector is to be stored in list 1. This decision may be basedon whether it is desirable to select reference pictures from atemporally preceding or succeeding picture. Which of the multiplepossible reference pictures is selected is determined according to thecollocated_ref_idx index.

FIG. 15 depicts the use of a collocated_from_10_flag by the decoder 220in decoding a according to the previous HEVC standard. Block 1502determines if the current slice type being computed is an intra orI-type. Such slices do not use temporally nearby slices in theencoding/decoding process, and hence there is no need to find atemporally nearby reference picture. If the slice type is not I-type,block 1504 determines whether the slice is a B-slice. If the slice isnot a B-type, it is a P-type slice, and the reference picture thatcontains the collocated partition is found in list 0, according to thevalue of collocated_ref_idx. If the slice is B-type, thecollocated_from_10_flag determines whether the reference picture isfound in list 0 or list 1. As the index indicates, the collocatedpicture is therefore defined as the reference picture having theindicated collocated_ref_idx in either list 0 or list 1, depending onthe slice type (B-type or P-type) and the value of thecollocated_from_10_flag. In one embodiment of HEVC, the first referencepicture (the reference picture having index [0] as shown in FIG. 13 isselected as the collocated picture).

Baseline Picture Parameter Set Syntax

FIGS. 16A and 16B are diagrams presenting a baseline PPS Raw ByteSequence Payload (RBSP) syntax. Syntax for dealing with extensions inthe PPS are shown in FIG. 16B. Logic 1602 determines if the media is tobe coded/decoded including a first extension and reads the appropriatesignaling and data. Logic 1602 comprises statements 1606-1616. Statement1606 reads a pps_extensiona1_flag, which indicates whether the firstextension has been selected for the coding/decoding process. In oneembodiment, a logical value of “1” indicates that the media is to beprocessed using the first extension, and a logical value of “0”indicates that the media is not to be processed using the firstextension. Statement 1608 is a conditional statement that directsexecution of statements 1612-1614 depending upon the value of a(previously read) transform_skip_enabled_flag. In particular, theillustrated logic performs the operations shown in statements 1612-1614if the transform_skip_enabled_flag is a logical “1” or true. Thetransform_skip_enabled_flag 1601 of the PPS syntax is shown in FIG. 16A.

Transform skipping is an extension that allows the DCT transform of a TUto be skipped under certain circumstances. Essentially, the DCTtransform has the property that for media with highly correlatedsignals, it results in outstanding energy compaction. However, for mediawith highly uncorrelated signals (e.g. media having a large amount ofdetail), the compaction performance is much less. For some media, theDCT transform process has so little compaction performance, the processis better skipped for better processing performance. Thetransform_skip_enabled_flag indicates when skipping the DCT transform ofa TU is permitted. This is described, for example, in “Early Terminationof Transform Skip Mode for High Efficiency Video Coding,” by Do KyungLee, Miso Park, Hyung-Do Kim and Je-Chang Jeong in the Proceedings ofthe 2014 International Conference on Communications, Signal Processingand Computers, which is hereby incorporated by reference. If thetransform_skip_enabled flag is a logical 1 (true), processing is routedto statement 1612 and 1614. Otherwise, processing is routed to statement1618. Statement 1612 performs the operation of reading a valuelog2_transform_skip_max_size_minus2, which indicates the maximum TU sizethat may be skipped (if the transform_skip_enabled_flag indicates thatperforming the DCT transform of the TU is permitted). Statement 1614performs the operation of reading a flag pps_extension2_flag indicatingif a further extension (extension2) is implemented.

Next, logic 1604 is performed. Logic 1604 includes statements 1618-1622.Statement 1618 is a conditional statement that routes processing to thelogic of statements 1620 and 1622 if the pps_extension2_flag is alogical 1. Statements 1620 and 1622 read additionalpps_extension_data_flags while RBSP data exists.

In the foregoing PPS design of HEVC range extension, thepps_extension2_flag accounts for as yet unidentified extension data.According to the logic described above, if pps_extension1_flag is true,pps_extension2_flag is present. If pps_extension1_flag is not true,pps_extension2_flag is not present. If pps_extension2_flag is notpresent, pps_extension2_flag is inferred to be equal to 0. Ifpps_extension2_flag is 0, there is no additional extension data.

This logical formulation always checks the value of pps_extension2_flagfor possible additional extension syntax regardless of the status ofpps_extension1_flag. However, if pps_extension1_flag is 0, there is noneed to check pps_extension2_flag, because if pps_extension1_flag is 0,pps_extension2_flag will not be present, and if pps_extension2_flag isnot present, it will inferred to be equal to 0, which indicates thatthere is no further extension data.

Related U.S. utility patent application Ser. No. 14/533,386, entitled“MODIFICATION OF PICTURE PARAMETER SET (PPS) FOR HEVC EXTENSIONS,”describes the modification of the foregoing syntax in which logic 1604(statements 1616-1620) of FIG. 16B is incorporated within theconditional statement 1608, and is executed only if pps_extension1_flagtests to a logical 1. This allowed the logic of statements 1610-1620 tobe skipped if pps_extension1_flag tests to a logical 0, thus savingexecution time.

This design works when there is only one PPS extension (e.g. thetransform skip extension) to be enabled and perhaps a second PPSextension to read additional data (e.g. signaled by thepps_extension2_flag) that is to be performed only if the first PPSextension is performed as well. However, if there are additional PPSextensions, this design in may not be efficient because the syntaxdemands that later extensions must parse all previous extension syntax,even though the previously executed extension and/or syntax may beindependent from or unrelated to later executed extension(s) and/orsyntax.

Improved Picture Parameter Set Syntax

FIGS. 17A-17D are diagrams presenting a modified PPS Raw Byte SequencePayload (RBSP) syntax. In summary, the modified RBSP syntax defines anextension presence signaling flag (pps_extension_present_flag) thatsignals whether the picture in the sequence is to be processed at leastin part according to at least one extension function. If thepps_extension_present_flag tests false, it is known that there are noPPS extensions to follow, and the need for syntax logic defining andhandling such extensions are no longer required and the processingassociated with executing such syntax logic is no longer performed, thussaving processing resources, memory resources, and processing time. Themodified PPS RBSP syntax also includes one or more extension signalingflags, each signaling the presence of an associated PPS extensionfunction. This increases the efficiency in the parsing and execution ofthe PPS syntax, because the one or more extension signaling flags,associated data and logical instructions need not be stored in thesyntax, read or executed by the processor.

In one embodiment, the PPS RBSP syntax is further modified so that theextension signaling flags are indexed and read iteratively. For example,n PPS extension signaling flags may be denoted as pps_extension_flag[i]wherein i is an index having a value from 0 to n−1. In one embodiment,seven PPS extension signaling flags are defined (n=7) may be used. Eachsuch individual PPS extension flag may control the parsing specificextension function syntax. For example, a first PPS extension flag maycontrols parsing of HEVC range extension related syntax and a second PPSextension flag may control parsing of MV-HEVC related syntax.

In another embodiment, the foregoing may be extended to accommodategreater than n (n>=8) extensions by use additional pps_extension_7bitssyntax. This additional syntax permits signaling of further extensionsthat may be designated in the future above seven PPS flags beinsufficient to the task. In a preferred embodiment, the number ofextension bits (as well as the maximum value of the index describedabove) is set to multiples of 8 bits (0-7) so that byte-by-byte parsingmay be easily accomplished.

FIG. 17A is a flow chart illustrating exemplary operations that can beemployed to encode/decode a sequence of a plurality of pictures usingone or more extension functions. In block 1700, an extension presencesignaling flag is read. The extension presence signaling flag indicateswhether the picture referenced by the PPS syntax is to be processed atleast in part according to at least one extension function. In block1702, a determination is made as to whether the read extension presencesignaling flag indicates that the picture associated with the PPS syntaxis to be processed at least in part with at least one extensionfunction. In one embodiment, this is accomplished by determining whetherthe extension function presence signaling flag has a first value. The“value” may be a logical value (e.g. true or false) or may be anumerical or alphanumerical value (e.g. 1 or 0) indicating a logicalvalue. If the extension presence signaling flag does not have a firstvalue (indicating that picture associated with the PPS syntax is to beprocessed without any extension functions, the operations shown inblocks 1704-1708 are bypassed. If the extension presence signaling flagis determined to indicate that the picture is to be decoded at least inpart according to at least one extension function, the first extensionfunction signaling flag is read as shown in block 1704, and regardlessof the value of the first extension function signaling flag, a secondextension function signaling function is read, as shown in block 1706.Hence, because the second extension function signaling flag is readregardless of the value or status of the previously read first extensionfunction signaling flag, the reading of the second extension functionsignaling flag is independent of the value of the read first extensionfunction signaling flag. This is in contrast to the syntax shown in FIG.16B, in which the pps_extension2_flag is only read by logic 1614 if thepps_extension1_flag tests true in logic 1608. Finally, as depicted inblock 1708, the extension function(s) signaled by the flags read inblocks 1704-1706 are performed.

FIG. 17B is a diagram presenting exemplary PPS syntax that can be usedto perform the operations shown in FIG. 17A to decode a sequence of aplurality of pictures using one or more extension functions. In theillustrated embodiment, the extension function(s) include the TU DCTtransform skipping extension functionality described above.

Logic 1712 reads the extension presence signaling flag. In theillustrated embodiment, the extension presence signaling flag comprise apps_extension_present_flag. Logic 1714 tests to determine if thepps_extension_present_flag is logically true, and only if so, executeslogic 1716-1740. If it is determined that the pps_extension_present_flagis logically false, processing is routed to logic 1740. Importantly,this means that no extension flags will be read, and no extensionfunction processing will be performed.

Logic 1716-1720 if FIG. 17B performs the operations described in blocks1704 and 1706 of FIG. 17A, and hence, reads the extension functionsignaling flag(s) (here, the pps_extension_flag[i] and/orpps_extension_7bits flag). In particular, logic 1716 and 1718 readpps_extension_flag[i] for i=0 to n−1 (in the exemplary embodiment n=1,so only one flag is read, namely pps_extension_flag[0]). Logic 1720reads a value pps_extension_7bits, which is used to signal additionalextension functionality beyond up to 7 extension functions referenced bypps_extension_flag[0]-pps_extension_flag[6].

Logic 1722 and 1728 tests to determine if the read pps_extension_flag[0]had a logical value indicating that the related extension function (TUDCT skipping) is desired. If the pps_extension_flag[0] has such a value(e.g. tests logically true), logic 1724-1730 is executed.

Logic 1724 tests to determine if transform skipping is enabled bytesting the transform_skip_enabled_flag. If enabled (e.g. thetransform_skip_enabled_flag tests true), logic 1726-1728 of the PPSsyntax is executed. Logic 1726-1728 reads the value represented bylog2_max_transform_skip_block_size_minus2, which specifies the maximumtransform unit (TU) block size for which the DCT transformation may beskipped.

Logic 1732 tests to determine if the value of pps_extension_7bits thatwas read by logic 1760 tests true. If so, logic 1734-1738 reads suchadditional signaling bits.

FIG. 17C is a flow chart further illustrating the exemplary PPS syntaxpresented in FIG. 17B, which as described above, reads all of theextension function signaling flags (e.g.pps_extension_flag[i]-pps_extension_flag[n−1]) first, and then performseach extension function, one after the other.

Referring to FIG. 17C, block 1750 reads the extension presence signalingflag. Block 1752 determines whether the extension presence signalingflag has a value indicating that at least one extension function is tobe performed. If the extension presence signaling flag indicates that noextension functions are to be performed, processing is routed afterblock 1758. If the extension presence signaling flag indicates that oneor more extension functions are to be performed, processing is routed toblock 1753, which reads all extension function signaling flags (e.g.pps_extension_flag[i]-pps_extension_flag[n−1]). Processing is thenpassed to block 1754, which tests to determine if the first extensionfunction signaling flag has a value that signals that the firstextension function is to be performed. FIG. 17B illustrates exemplarysyntax for performing this test at logic 1722.

If the extension function signaling flag indicates that the extensionfunction is not to be performed, processing is around blocks 1756 and1758. Syntax for performing these operations is exemplified by logic1722 to logic 1730 of FIG. 17B. If the extension function signaling flagindicates that the extension function is to be performed, processing isrouted to block 1756, and at least a portion of the extension functionprocessing is performed. Syntax for performing these operations isillustrated in FIG. 17B by logic 1724-1728, which reads the maximumtransform unit block size for which the DCT transform may be skipped ifindicated by the transform_skip_enabled_flag 1601.

Block 1758 tests to determine whether all extension functions have beenconsidered. If all extension functions have been considered, processingconcludes (analogous to logic 1740 in the syntax illustrated in FIG.17B). If all extension functions have not been considered, processing isrouted to block 1760, which brings the next function signaling flag forconsideration by block 1754.

The foregoing illustrates processing logic in which all of the extensionfunction signaling flags are read, and each extension function is thenexecuted, one at a time. This embodiment is especially useful inembodiments wherein the extension function signaling flag is read withan incremented index as shown in logic 1716 and 1718, as it decouplesthe reading of the flag (which is indexed) from the execution of theextension function itself (which may or may not be indexed). Forexample, the processing loop represented by blocks 1754-1760 may beperformed by simply including syntax for performing each extensionfunction, one after the other (e.g. executing logic 1754-1756 and thenexecuting further logic to perform the next extension function, withlogical statements interposed between logic 1756 and 1758). Or, they maybe performed using an incremented index, which may be the same indexused to read the extension function signaling flags, or a differentindex.

FIG. 17D is a diagram of a flow chart illustrating an alternateembodiment wherein instead of reading all extension function signalingflags before beginning to perform the extension functions themselves,each extension function signaling flag is read and the extensionfunction is performed before reading the next extension functionsignaling flag Block 1760 reads a first extension function signalingflag (which may be indexed), and block 1762 tests whether the read firstextension function signaling flag indicates that the first extensionfunction is to be performed. If the function is not to be performed,processing is routed to block 1768, and the extension function is notperformed. However, if the first extension function signaling flagindicates that the extension function is to be performed, processing isrouted to block 1764, where such processing is performed before routingprocessing to block 1768. Upon completion of this processing, block 1768determines if all extension function signaling flags have been read. Ifso, processing exits, but if not, the next extension function signalingflag is considered, as illustrated by block 1770. An second extensionfunction signaling flag is read, and the operations of blocks 1760-1768is repeated for that second extension function signaling flag and itsassociated second extension function. This may also be accomplished viathe use of one or more incremented indexes, and a different index wouldbe used for reading the extension function signaling flags andperforming the extension functions themselves.

FIG. 18 is a diagram presenting an embodiment of the PPS syntax for HEVCrange extension. As before, the pps_extension_present_flag read in logicstatement 1712 specifies that at least one pps_extension_flag[i] ispresent in the PPS syntax. This pps_extension_present_flag is used inlogic statement 1714 to indicate that logic statements 1716 and 1718should be performed, and these logical statements readpps_extension_flag[i] for i=0 to n. A pps_extension_flag[i] value of 1specifies that the syntax structure for the associated pps_extension ispresent, while a pps_extension_flag[i] value of 0 specifies that thesyntax structure for the pps_extension associated with the flag is notpresent.

In the exemplary syntax shown in FIG. 18, a pps_extension_flag[0] valueof 1 specifies that the following HEVC range extension-related elementsare present in the PPS RBSP syntax structure, as shown in logicstatements 1724, 1726 and 1804-1820:

-   -   log2_max_transform_skip_block_size_minus2;    -   luma_chroma_prediction_enabled_flag;    -   chroma_qp_adjustment_enabled_flag;    -   diff_cu_chroma_qp_adjustment_depth;    -   chroma_qp_adjustment_table_size_minus1;    -   cb_qp_adjustment;    -   cr_qp_adjustment.

Conversely, a pps_extension_flag[0] equal to 0 specifies that thesesyntax elements are not present.

Further, a pps_extension_7bits value of 0 specifies that no morepps_extension_data_flag syntax elements are present in the PPS RBSPsyntax structure, and logic statement 1822 skips logic statements 1824and 1828. The pps_extension_7bits shall have a value of 0 in bit streamsconforming to legacy specification versions, as pps_extension_7bitsvalues not equal to 0 are reserved for future use by ITU-T/ISO/IEC. HEVCDecoders shall allow the value of pps_extension_7bits to be not equal to0 and shall ignore all pps_extension_data_flag syntax elements in an PPSNAL unit.

FIGS. 19A-19C show further alternate embodiments of extension signalingsyntax. FIG. 19A illustrates a generalized syntax in which the extensionpresence signaling flag (pps_extension_present_flag) is used to signalwhether further extension function syntax is present in the PPS. Asbefore, logic statements 1712 reads the pps_extension_present_flag.Logic statement 1714 commands execution of logic statements 1716-1742only if the pps_extesion_present_flag indicates that syntax for one ormore extension functions is present in the PPS. Logic statement 1716reads a pps_extension_flag[i] for all values of i, and logic statement1720 reads pps_extension_7bits. Logic statements 1732-1740 read apps_extension_data_flag and associated data.

FIG. 19B illustrates a PPS syntax wherein the extension functionsignaling flags are read in separate statements, rather than via anincremented index within a processing loop. Specifically, logicstatements 1902-1906 read a first flag (pps_range_extension_flag)indicating that the range extension processing is to be performed, asecond flag (pps_multilayer_extension_flag), indicating that multilayeror multi-view (MV-HEVC) extension processing is to be performed, and athird flag (pps_extension_bits6) for reading further extension data.Logic statements 1910-1912 perform the pps_range_extension( ) processing(which may be disposed in a separate PPS range extension syntaxreferenced by the pps_range_extension( ) logical statement) as indicatedby the pps_range_extension_flag read by logic statement 1902. Logicstatements 1914-1916 perform the pps_multilayer_extension( ) (alsopossibly specified in distinct PPS syntax referenced by thepps_multilayer_extension( ) logical statement) as indicated by thepps_multilayer_extension_flag. Logic statements 1918-1926 read apps_extension_data_flag and associated data.

FIG. 19C illustrates a PPS syntax where the extension function signalingflags are read using an incremented index, but tested and used toperform extension processing in separate, unindexed statements.Specifically, logic statements 1930-1932 read two pps_extension_flags,namely pps_extension_flag[0] and pps_extension_flag[1] using an index itaking the value of 0 and 1. Logic statement 1934 reads thepps_extension_6bits value, and logic statements 1938-1952 operateanalogously to logic statements 1910-1926, except the pps_extension_flagis referenced and distinguished by an index of [0] or [1] rather than adifferent name.

Other embodiments of the foregoing syntax are also envisioned. Forexample, it is possible to group the extension presence signaling flags(e.g. pps_extension_flag) by type or category. This permits extensionsthat have similar data requirements to be signaled and processedtogether, thereby saving syntax statements and decoder processing.

As described above, the signaled extension functions may be independent,or may be functionally related. For example, a second extension functionmay require use of a result of a first (previously processed orexecuted) extension function, before the second extension function maybe completed. Or, the second extension function may be mutuallyexclusive from the first extension function (e.g. either the firstextension function or the second extension function are to be performed,but not both). Or, the second extension function may be a function thatwould not be performed unless the first extension function is alsoperformed, hence the second extension function is only implicated orperformed in the processing sequence if the first extension function isalso performed. For example, a computation may require an output orresult from both the first extension function and the second extensionfunction, and hence, existence of the first extension functionnecessarily implicates the second extension function and vice-versa.

The foregoing operations are described with respect to a decodingprocess, which can take place in either a the source decoder 220 or anencoder 202, as a part of the encoding process. The encoding process mayalso be expressed as comprising determining if a slice of the one ormore slices is an inter-predicted slice according to slice type data,and if the slice is an inter-predicted slice, configuring a firstparameter in the slice header associated with the slice to a valuesignaling enablement of a state of weighted prediction of image dataassociated with the slice.

Hardware Environment

FIG. 20 illustrates an exemplary processing system 2000 that could beused to implement the embodiments of the invention. The computer 2002comprises a processor 2004 and a memory, such as random access memory(RAM) 2006. The computer 2002 is operatively coupled to a display 2022,which presents images such as windows to the user on a graphical userinterface 2018B. The computer 2002 may be coupled to other devices, suchas a keyboard 2014, a mouse device 2016, a printer, etc. Of course,those skilled in the art will recognize that any combination of theabove components, or any number of different components, peripherals,and other devices, may be used with the computer 2002.

Generally, the computer 2002 operates under control of an operatingsystem 2008 stored in the memory 2006, and interfaces with the user toaccept inputs and commands and to present results through a graphicaluser interface (GUI) module 2018A. Although the GUI module 2018A isdepicted as a separate module, the instructions performing the GUIfunctions can be resident or distributed in the operating system 2008,the computer program 2010, or implemented with special purpose memoryand processors. The computer 2002 also implements a compiler 2012 whichallows an application program 2010 written in a programming languagesuch as COBOL, C++, FORTRAN, or other language to be translated intoprocessor 2004 readable code. After completion, the application 2010accesses and manipulates data stored in the memory 2006 of the computer2002 using the relationships and logic that was generated using thecompiler 2012. The computer 2002 also optionally comprises an externalcommunication device such as a modem, satellite link, Ethernet card, orother device for communicating with other computers.

In one embodiment, instructions implementing the operating system 2008,the computer program 2010, and the compiler 2012 are tangibly embodiedin a computer-readable medium, e.g., data storage device 2020, whichcould include one or more fixed or removable data storage devices, suchas a zip drive, floppy disc drive 2024, hard drive, CD-ROM drive, tapedrive, etc. Further, the operating system 2008 and the computer program2010 are comprised of instructions which, when read and executed by thecomputer 2002, causes the computer 2002 to perform the steps necessaryto implement and/or use the invention. Computer program 2010 and/oroperating instructions may also be tangibly embodied in memory 2006and/or data communications devices 2030, thereby making a computerprogram product or article of manufacture. As such, the terms “articleof manufacture,” “program storage device” and “computer program product”as used herein are intended to encompass a computer program accessiblefrom any computer readable device or media.

The processing system 2000 may also be embodied in a desktop, laptop,tablet, notebook computer, personal data assistant (PDA), cellphone,smartphone, or any device with suitable processing and memorycapability. Further, the processing system 2000 may utilize specialpurpose hardware to perform some or all of the foregoing functionality.For example the encoding and decoding processes described above may beperformed by a special purpose processor and associated memory.

Those skilled in the art will recognize many modifications may be madeto this configuration without departing from the scope of the presentdisclosure. For example, those skilled in the art will recognize thatany combination of the above components, or any number of differentcomponents, peripherals, and other devices, may be used. For example,particular functions described herein can be performed by hardwaremodules, or a processor executing instructions stored in the form ofsoftware or firmware. Further, the functionality described herein can becombined in single modules or expanded to be performed in multiplemodules.

Conclusion

The foregoing description of the preferred embodiment has been presentedfor the purposes of illustration and description. It is not intended tobe exhaustive or to limit the disclosure to the precise form disclosed.Many modifications and variations are possible in light of the aboveteaching. It is intended that the scope of rights be limited not by thisdetailed description, but rather by the claims appended hereto.

What is claimed is:
 1. A method of decoding a plurality of pictures,each picture processed at least in part according to a picture parameterset, the method comprising: receiving a bitstream comprising theplurality of pictures and a picture parameter set and at least onetransform unit; parsing the picture parameter set to determine for apicture in the plurality of pictures whether apps_extension_present_flag signaling flag specifies presence of syntaxstructure pps_extension_Xbits at a picture level for the picture,wherein the pps_extension_present_flag and pps_extension_Xbits signalingflags, when present, are adaptable per picture in the plurality ofpictures, and wherein the pps_extension_Xbits signaling flag isrepresented in the picture parameter set by multiple bits, where X=thenumber of said bits; parsing the pps_extension_Xbits syntax structure todetermine if any pps_extension_data_flag syntax structures are presentin the picture parameter set; wherein pps_extension_Xbits shall be equalto 0 for bitstreams conforming to High Efficiency Video Coding (HEVC)profiles, and wherein pps_extension_Xbits not equal to 0 causes thepps_extension_data_flag syntax structures in a picture parameter set NALunit to be ignored during decoding.
 2. The method of claim 1, furthercomprising: reading a first extension function signaling flag signaledin the picture parameter set and signaling a first extension functionfor decoding the picture; reading a second extension function signalingflag signaled in the picture parameter set and signaling a secondextension independently of a value of the read first extension functionsignaling flag for decoding the picture; performing decode processing atthe picture level in accordance with a syntax structure in the pictureparameter set according to the first extension function and the secondextension function at the picture level in accordance with the syntaxstructure in the picture parameter set; for each picture, reading afurther extension presence signaling flag after processing the firstextension function and the second extension function without processingfurther extension functions; and for each picture, determining from thefurther extension presence signaling flag that the read extensionpresence signaling flag indicates that there is no extensions to follow,and upon determining no extensions follow, the decoding for therespective picture proceeds without checking or executing further syntaxlogic to handle processing of extensions, wherein the second extensionfunction is independent from the first extension function.
 3. The methodof claim 2, further comprising: determining if the first extensionfunction signaling flag indicates that the picture is to be processed atleast in part according to the first extension function.
 4. The methodof claim 3, further comprising: performing the first extension functiononly if the first extension function signaling flag indicates that thepicture is to be processed at least in part according to the firstextension function.
 5. The method of claim 4, further comprising:determining if the second extension function signaling flag indicatesthat the picture is to be processed at least in part according to thesecond extension function, and performing the second extension functiononly if the second extension function signaling flag indicates that thepicture is to be processed at least in part according to the secondextension function.
 6. The method of claim 2, wherein the firstextension function signaling flag is uniquely associated with a firstvalue of an index, and the second extension function signaling flag isuniquely associated with a second value of the index, and wherein: thereading the first extension function signaling flag and the secondextension function signaling flag comprises: reading the first extensionfunction signaling flag value according to the index; incrementing theindex; and reading the second extension function signaling flag valueaccording to the incremented index.
 7. The method of claim 6, wherein:the first extension function comprises a range extension function; andthe second extension function comprises a high efficiency video coding(HEVC) multilayer or multiview extension function.
 8. An apparatus fordecoding a plurality of pictures, each picture processed at least inpart according to a picture parameter set, the apparatus, comprising: aprocessor; a memory, communicatively coupled to the processor, thememory storing a plurality of instructions comprising instructions for:receiving a bitstream comprising the plurality of pictures and a pictureparameter set and at least one transform unit; parsing the pictureparameter set to determine for a picture in the plurality of pictureswhether a pps_extension_present_flag signaling flag specifies presenceof syntax structure pps_extension_Xbits at a picture level for thepicture, wherein the pps_extension_present_flag and pps_extension_Xbitssignaling flags, when present, are adaptable per picture in theplurality of pictures, and wherein the pps_extension_Xbits signalingflag is represented in the picture parameter set by multiple bits, whereX=the number of said bits; parsing the pps_extension_Xbits syntaxstructure to determine if any pps_extension_data_flag syntax structuresare present in the picture parameter set; wherein pps_extension_Xbitsshall be equal to 0 for bitstreams conforming to High Efficiency VideoCoding (HEVC) profiles, and wherein pps_extension_Xbits not equal to 0causes pps_extension_data_flag syntax structures in the pictureparameter set NAL unit to be ignored during decoding.
 9. The apparatusof claim 8, further comprising: reading a first extension functionsignaling flag signaled in the picture parameter set and signaling afirst extension function for decoding the picture; reading a secondextension function signaling flag signaled in the picture parameter setand signaling a second extension independently of a value of the readfirst extension function signaling flag for decoding the picture;performing decode processing at the picture level in accordance with asyntax structure in the picture parameter set according to the firstextension function and the second extension function at the picturelevel in accordance with the syntax structure in the picture parameterset; for each picture, reading a further extension presence signalingflag after processing the first extension function and the secondextension function without processing further extension functions; andfor each picture, determining from the further extension presencesignaling flag that the read extension presence signaling flag indicatesthat there is no extensions to follow, and upon determining noextensions follow, the decoding for the respective picture proceedswithout checking or executing further syntax logic to handle processingof extensions, and wherein the second extension function is independentfrom the first extension function.
 10. The apparatus of claim 9, whereinthe instructions further comprise instructions for: determining if thefirst extension function signaling flag indicates that the picture is tobe processed at least in part according to the first extension function.11. The apparatus of claim 9, wherein the first extension functionsignaling flag is uniquely associated with a first value of an index,and the second extension function signaling flag is uniquely associatedwith a second value of the index, and wherein: the instructions forreading the first extension function signaling flag and the secondextension function signaling flag comprises instructions for: readingthe first extension function signaling flag value according to a theindex; incrementing the index; and reading the second extension functionsignaling flag value according to the incremented index.
 12. Theapparatus of claim 11, wherein: the first extension function comprises arange extension function; and the second extension function comprises ahigh efficiency video coding (HEVC) multilayer or multiview extensionfunction.